home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Meeting Pearls 4
/
Meeting Pearls Vol. IV (1996)(GTI - Schatztruhe)[!].iso
/
Pearls
/
comm
/
Point
/
TheAnswer
/
TAHeader.dok
< prev
next >
Wrap
Text File
|
1993-12-22
|
84KB
|
944 lines
HINWEISE:
1. Textbreite 130 zeichen. mit schmaler Schrift ausdrucken
2. Nächste Seite beginnt bei "^L"
3. Orignal in LaTex, dies ist eine Nachkonvertierung nach ASCII und
nicht besonders schön.
4. Wer diese sauber mit 80 Zeichen Bretite formatiert, kann mir das
Ergebnis schicken...
^L
TheAnswer III
1 1
Das Amiga Point-Programm f"ur Z-Netz und
1
ZConnect kompatible Datennetze
Deutsche Dokumentation "uber
Header und Formate
Nachrichtenheader in TheAnswer und ZConnect
vom 20.12.1993
Autoren und Verantwortliche:
Felix Heine, Martin Husemann, Matthias Jung, Wolfgang Mexner, padeluun, Hartmut
Schr"oder und Rena Tangens
TheAnswer-Spezifikationen und LaTex-Satz:
Toni G"unzel-Peltner
ZERBERUS(R) ist ein eingetragenes Warenzeichen von Wolfgang Mexner.
ZCONNECT(R) ist ein eingetragenes Warenzeichen der ZERBERUS GmbH.
____________________________________________________1
Copyrights in der Einleitung und in der Hauptdokumentation zu TheAnswerIII
^L
Inhaltsverzeichnis
1 Einleitung 2
1.1 Das Copyright der TheAnswer-Header : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2
1.2 Das Copyright von ZConnect : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2
2 Benutzung von Header-Variablen 3
2.1 Format : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3
2.2 Parameter : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 3
2.3 Bedingte Verzweigung durch IF/ENDIF : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4
2.4 Konstante Hilfsvariablen : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 5
3 Die m"oglichen Header-Informationen 6
3.1 ZConnect-Header : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 6
3.2 Weitere Headerzeilen von TheAnswer : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11
3.3 Lokale Headerzeilen von TheAnswer : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
3.4 Weitere Headerzeilen : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12
Index 14
1
^L
Kapitel 1
Einleitung
Diese Dokumentation beschreibt Format und Aufbau von Header-Zeilen in ZConnect-Nachrichten-Headern.
TheAnswerIII benutzt dieses Format f"ur die Daten"ubertragung unter ZConnect und zur internen
Datenverwaltung.
Hier werden alle unter ZConnect Version 3.00 und, bis zum Erscheinungsdatum bekannten, ZConnect
Version 3.10 benutzten Nachrichtenheader beschrieben. F"ur Benutzer von TheAnswerIII ist diese Kenntnis
notwenidg, wenn die frei definierbaren Header-Dateien und ihre Variablen, die sich an ZConnect-Header
anlehnen, ver"andert werden sollen.
1.1 Das Copyright der TheAnswer-Header
Alle Rechte liegen bei Toni G"unzel-Peltner. Lokale TA-Header d"urfen unver"andert in allen (auch
kommerziellen) Applikationen lizenzfrei implementiert werden. In diesem Fall muss in der jeweiligen
Dokumentation ein Copyright-Hinweis auf die TheAnswerIII-Header erfolgen.
1.2 Das Copyright von ZConnect
Dieser Copyright-Hinweis betrifft die vollst"andige ZConnect-Dokumentation, auch wenn hier nur
die Header-Formate erkl"art werden.
Alle Rechte liegen bei den Autorinnen. Dieses Dokument darf beliebig vervielf"altigt und unver"andert
weitergegeben werden. ZCONNECT darf unver"andert in allen (auch kommerziellen) Applikationen lizenzfrei
implementiert werden. In diesem Fall muss in der jeweiligen Dokumentation und im jeweiligen Programm
an gleicher Stelle, wie die Nennung der Programmautorinnen der Hinweis: "Oc < jahreszahlen > f"ur
ZCONNECT: ZERBERUS GmbH, Friedland (FRG). ZCONNECT ist ein eingetragenes Warenzeichen der
ZERBERUS GmbH, Friedland (FRG)" beziehungsweise eine "Ubersetzung in der Landessprache des jeweiligen
Programms erscheinen. Werden in einem Programm keine Autorinnen oder Rechte genannt, muss der Hinweis
an angemessener Stelle erfolgen.
Die Dokumentation kann im Buchhandel unter der internationalen Bestellnummer ISBN 3-9802182-3-6
oder via BTX "uber die Bestellseiten des FOEBUD# oder direkt bei der ZERBERUS GmbH bestellt werden
(Vorkasse, Scheck oder bar). Die Doku ist im Format DIN A 4, gebunden, mit einer Diskette versehen und
kostet 30 DM.
2
^L
Kapitel 2
Benutzung von Header-Variablen
2.1 Format
Header, die in einer Kopfdatei von TheAnswerIII benutzt werden, haben die Aufgabe einer Variablen.
Sie werden, wenn die Datei von TheAnswerIII eingelesen wird, mit den Daten des Headers der aktuellen
Nachricht gef"ullt. Das Format lautet dabei:
%HeaderID:
Zuerst kommt das Prozentzeichen (%), um TheAnswerIII mitzuteilen, dass nun eine Variable folgt. Danach
folgt ohne Leerzeichen o."a. die HeaderID, also ein Wort, dass den Header identifiziert. z.B. bedeutet "EMP"
Nachrichten-Empf"anger. Welche Header-IDs m"oglich sind, ist in den n"achsten Kapiteln aufgelistet. Nach der
HeaderID folgt ein Doppelpunkt (:), um TheAnswerIII mitzuteilen, dass die Variable nun zu Ende ist.
Ist eine Header-ID mehrfach in einer Nachricht, werden alle Eintr"age untereinander angezeigt.
2.2 Parameter
Besondere Variablen ben"otigen teilweise Parameter, andere Variablen k"onnen mit Hilfe bestimmter
Parameter formatiert werden. Ein Parameter wird wie eine Variable in die Header-Datei geschrieben:
%Parameter:
Also Prozentzeichen, Parametername, Doppelpunkt.
Wird ein Parameter angegeben, so wird er auf die n"achste Variable, die in der gleichen Zeile kommt
angewandt. Wieviel Text dazwischen steht ist TheAnswerIII egal.
TheAnswerIII kennt folgende Parameter:
____________________________________________________________________________________________________________________
|__DATUM___________________________________________________________Datum_aus_Datum/Zeit-Header_filtern.__|__________||
| Verschiedene Header speichern ein Datum. Diese Daten haben ein sehr schlecht |
| |
| lesbares Format. (siehe z.B. EDA). Wird nun vor eine Datumsvariable dieser |
| Parameter gesetzt, filtert TheAnswerIII aus dem nachfolgenden Header das |
| |
| Datum aus und gibt es im Format Tag TT.MM.JJJJ aus. Als Tag wird der |
| Wochentag mit zwei Buchstaben angegeben, danach folgt Tag, Monat und |
| |
| Jahr in Zahlenform. Beispiel: "%DATUM:%EDA:" gibt das Absendedatum einer |
| |
|_______________Nachricht_aus.______________________________________________________________________________________|_
|__ZEIT___________________________________________________________Uhrzeit_aus_Datum/Zeit-Header_filtern.__|_________||
| Hier gilt das gleiche, wie bei "DATUM", nur wird aus der Variablen die |
| Uhrzeit im Format SS.MM.SS gefiltert. (Stunde, Minute, Sekunde). Beispiel: |
| |
|_______________"%ZEIT:%EDA:"_gibt_die_Absendeuhrzeit_einer_Nachricht_aus.__________________________________________|
3
^L
KAPITEL 2. BENUTZUNG VON HEADER-VARIABLEN 4
______________________________________________________________________________________________________________________
|__NAME____________Namen_aus_Netzadresse_filtern______________________________________________________________________||
| Filtert aus der n"achsten Variablen den Usernamen aus, wenn diese eine Netzadresse |
| |
| ist. Beispiel: "%NAME:%ABS:" filtert den Namen aus der Absenderadresse und |
| macht so aus "WEGAR@AMC.zer.sub.org" ein "Wegar". Bei der Wandlung |
| |
| "NAME" werden alle Buchstaben, bis auf den ersten in Kleinschrift gewandelt, um |
| besser auszusehen. Ist im Namen ein Sonderzeichen, wie bei "P.FROEHLICH" ein |
| |
| Punkt, so wandelt TheAnswerIII den ersten Buchstaben nach dem Sonderzeichen |
| |
|________________wieder_gross:_P.Froehlich.__________________________________________________________________________|__
|__USER____________Usernamen_aus_Netzadresse_filtern__________________________________________________________________||
| Filtert aus der n"achsten Variablen den Usernamen aus, wenn diese eine Netzadresse |
| |
| ist. Beispiel: "%USER:%ABS:" filtert den Namen aus der Absenderadresse |
| und macht so aus "WEGAR@AMC.zer.sub.org" ein "WEGAR". Im Gegensatz |
| |
| zu NAME wird die Schreibweise nicht ver"andert und auch eventuelle Gate- |
| Adressierungen werden erhalten. Ein "WEGAR%TURBO@AMNET.zer.sub.org" |
| |
| w"urde mit NAME formatiert "Wegar" und mit USER formatiert |
| |
|________________"WEGAR%TURBO"_ergeben.______________________________________________________________________________|__
|__SERVER__________Mailboxnamen_aus_Netzadresse_filtern_______________________________________________________________||
| Filtert aus der n"achsten Variablen den Namen der Serverbox heraus, wenn diese |
| eine Netzadresse ist. Beispiel: "%SERVER:%ABS:" filtert den Server aus der |
| |
|________________Absenderadresse_und_macht_so_aus_"WEGAR@AMC.zer.sub.org"_ein_"AMC"._________________________________|__
|__DOMAIN__________Netzdomain_aus_Netzadresse_filtern_________________________________________________________________
| Filtert aus der n"achsten Variablen die Domain Serverbox heraus, wenn |
| diese eine Netzadresse ist. Beispiel: "%DOMAIN:%ABS:" filtert die Domain |
| |
| aus der Absenderadresse und macht so aus "WEGAR@AMC.zer.sub.org" ein |
| |
|________________"zer.sub.org"_ohne_vorangestellten_Punkt!___________________________________________________________|_
2.3 Bedingte Verzweigung durch IF/ENDIF
Mit TheAnswerIII k"onnen Header-Files durch eine einfache IF/ENDIF-Kombination bestimmte Abschnitte
aus Header ausgeklammert werden, wenn eine Bedingung zutrifft. IF und ENDIF beginnen genau wie
Variablen oder Parameter mit einem Prozentzeichen (%) und enden mit einem Doppelpunkt (:).
IF hat nur eine Aufgabe in TheAnswerIII-Header-Files: Es pr"uft, ob der danach folgende Header in der
Nachricht ist oder nicht. Findet TheAnswerIII den Header wird IF ignoriert, anderfalls arbeitet The-
AnswerIII erst ab der Stelle weiter, ab der ein ENDIF gefunden wird. IF-Schleifen k"onnen nicht verschachtelt
werden. Bevor ein neues IF folgt, muss das Vorg"anger-IF mit ENDIF beendet sein.
Beispiel:
%IF:%Z-NETZ-ABS:
ZNetz V 3.8-Nachricht:
Z-Netz-Emp : %X-TA-ZNETZ-EMP:
Z-Netz-Abs : %ZNETZ-ABS:
Z-Netz-ID : %X-TA-ZNETZ-ID:
Z-Netz-Text : %ZNETZ-TEXT:
%ENDIF:
Nur wenn in der Nachricht der Header Z-NETZ-ABS zu finden ist, werden die nachfolgenden Zeilen
abgearbeitet und die anderen Header dargestellt, die hier im Beispiel alle Spezial-Header sind, die nur
Nachrichten besitzen, die nicht mit ZConnect, sondern mit dem veralteten Z-Netz-Verfahren transportiert
wurden.
Ohne IF wurde eine Header-Datei mit diese Anordnung 4 Leerzeilen erzeugen, mit IF wird dieser Abschnitt
einfach ausgeklammert.
^L
KAPITEL 2. BENUTZUNG VON HEADER-VARIABLEN 5
2.4 Konstante Hilfsvariablen
TheAnswerIII kenn drei interne Variablen, die nur in Header-Dateien benutzt werden, um bestimmte Daten
darstellen zu k"onnen. Sie stehen immer allein und ben"otigen keine Parameter:
_________________________________________________________________________________________________________________________
|__HEUTE_____________Aktuelles_Datum_ins_Header-File_schreiben___________________________________________________________
| %HETUE: wird bei Formatierung immer durch das aktuelle Datum ersetzt. Dabei |
| |
|____________________wird_die_gleiche_Schreibweise_benutzt,_als_w"are_der_Parameter_DATUM:_angegeben.____________________|_
|__JETZT_____________Aktuelle_Uhrzeit_ins_Header-File_schreiben__________________________________________________________
| %JETZT: wird bei Formatierung immer durch das aktuelle Uhrzeit ersetzt. Dabei |
| |
|____________________wird_die_gleiche_Schreibweise_benutzt,_als_w"are_der_Parameter_ZEIT:_angegeben._____________________|_
|__REPLY_____________Antowrtenz"ahler_formatiert_darstellen______________________________________________________________
| %REPLY: liefert den im Inhaltmen"u links vom Betreff stehenden Antwortenz"ahler. |
| |
| Dabei wird jedoch nicht nur die Zahl dargestellt (das geht mit der Variablen |
| "REPLY-LEVEL"), sondern es wird noch der Text "Re^" vorangestellt. In |
| |
| Kombination mit dem Betreff einer Nachricht (BET), kann man so beides |
| |
| zusammen und lesbar darstelllen: |
| %REPLY:%BET: ergibt bei dem Betreff "Neues zu TheAnswer" und einem |
| |
|____________________Antwortenz"ahler_von_4:_"Re^4:_Neues_zu_TheAnswer"__________________________________________________|_
|__UNKNOWN___________Unbekannte_Header_darstellen________________________________________________________________________
| %UNKNOWN: Es kann immer wieder vorkommen, dass ein Header u"bers Netz |
| kommt, denn TheAnswerIII nicht kennt. Wird diese Variable in einem Headerfile |
| |
| gefunden werden an dieser Stelle alle Header, die hier nicht beschrieben sind mit |
| |
|____________________ihrer_Header-ID_angezeigt.__________________________________________________________________________|
^L
Kapitel 3
Die m"oglichen Header-Informationen
3.1 ZConnect-Header
Die hier gezeigten Header-IDs geh"oren zum Standard-Umfang von ZConnect, und werden von jeder Software,
die ZConnect-Kompatibel ist, benutzt und unterst"utzt.
_______________________________________________________________________________________________________________________________
|__ABS_____________________Nur_einmal_________Pflicht___________________________________________________________Absenderin__|__
| Die Adresse, "uber die die Absenderin erreichbar ist, komplett mit Absendersystem, |
| |
|__________________________Domainangabe_und_evtl._Realname.____________________________________________________________________*
*|_
|__ANTWORT-AN:________________________________optional______________________________________Alternative_Antwortadresse__|______
| Eine private Antwort an die Absenderin ist nicht an die ABS-Adresse zu |
| |
| schicken, sondern an die hier angegebene. Dies erm"oglicht Benutzerinnen mehrerer |
| MailBoxen, alle Antworten an die "Hauptadresse" schicken zu lassen. Auch bei |
| |
| automatisch generierten Nachrichten (Absenderin "Mailer-Daemon") kann so eine |
| |
|__________________________Ansprechpartnerin_f"ur_R"uckfragen_angegeben_werden.________________________________________________*
*|_
|__BET_____________________Nur_einmal_________Pflicht________________________________________________________________Betreff__|*
*__
|__BEZ_____________________mehrfach___________optional________________________________________________________________Bezug__|_
| Wenn diese Nachricht eine Antwort auf eine "altere Nachricht ist, gibt der Bezug |
| |
|__________________________die_Message-ID_der_Originalnachricht_an.____________________________________________________________*
*|_
|__DDA_____________________Nur_einmal_________optional_________________________________________________________Dateidatum__|___
| Gibt das Datum der letzten "Anderung einer Datei an. Das Format des Datums ist |
| |
|__________________________unter_EDA_beschrieben.______________________________________________________________________________*
*|_
|__DISKUSSION-IN______________________________optional________________________________________Alternative_Reply-Adresse__|_____
| Gibt die Empf"angerin an, die bei "offentlichen Antworten benutzt werden soll. Dies |
| |
| ist immer dann sinnvoll, wenn eine Nachricht in mehrere Bretter geschickt wird, die |
| darauf folgende Diskussion aber auf ein Brett beschr"ankt werden soll. Es k"onnen |
| |
| aber auch reine Informationsbretter von Diskussionsbeitr"agen freigehalten werden, |
| |
|__________________________indem_die_Antworten_auf_ein_passendes_Diskussions-Brett_dirigiert_werden.___________________________*
*|_
|__EB______________________mehrfach___________optional_____________________________________________Empfangsbest"atigung__|_____*
*||
| Ist dieser Header vorhanden, verschickt das Zielsystem, sobald die Nachricht von |
| |
| ihm empfangen wird, eine Empfangsbest"atigung an die Absenderin. Benutzt die |
| Empf"angerin einen Point und ist dieser auch mit ZCONNECT angeschlossen, wird |
| |
| die Empfangsbest"atigung nicht beim Empfang in der MailBox ausgel"ost, sondern |
| erst vom Point. In allen anderen F"allen wird beim Einsortieren der Nachricht in |
| |
| die MailBox sofort die Best"atigung verschickt. Best"atigt wird der Empfang, nicht |
| |
| das Lesen der Nachricht (Datenschutz!). |
|__________________________________________________________________________________________________(Fortsetzung_n._Seite)__|___
6
^L
KAPITEL 3. DIE MO"GLICHEN HEADER-INFORMATIONEN 7
_______________________________________________________________________________________________________________________
|__EB_______________________________________________________________________________________________(Fortsetzung)__|___
| Der EB Header kann auch eine Adresse enthalten, in diesem Fall geht die |
| Empfangsbest"atigung nicht an die Absenderin, sondern an die angegebene Adresse. |
| |
| Sind mehrere EB Header vorhanden, erh"alt jede dort aufgef"uhrte Adresse eine |
| |
| Best"atigung. |
| In der Best"atigung ist im BEZ Header die Message-ID der best"atigten Nachricht |
| |
|_________________anzugeben._Weiterhin_ist_ein_Header_STAT:EB_zu_setzen.______________________________________________|__
|__EDA____________Nur_einmal_________Pflicht________________________________________________________________Datum__|___||
| Das Erstellungsdatum wird dabei im Format JJJJMMTThhmmss[S/W](+/- |
| offset) angegeben, wobei S oder W f"ur Sommer bzw. Winterzeit steht, (offset) |
| |
|| ist die Zeitzone als Unterschied in Stunden zur GMT. ||
| Dabei wird die Zeit immer als GMT angegeben, die Zeitzone/Sommerzeit |
| erm"oglicht lediglich das Umrechnen dieser universellen Zeit auf die lokale Zeit |
| |
| der Absenderin. |
| In Deutschland gelten die Zeitzonen MET und im Sommer MEST. Diese w"urden |
| durch die Zus"atze "W+1" bzw. "S+2" dargestellt Durch die Darstellung als |
| |
| GMT sind die JJJJMMTThhmmss Angaben auch w"ahrend der Umstellung von |
| |
|| Sommer- auf Winterzeit und umgekehrt kontinuierlich. ||
| Falls die lokale Uhrzeit nicht um ganze Stundenbetr"age von GMT abweicht, wird |
| dem Offset einen Minutenangabe zugef"ugt. Beispiel: "W-9:30" f"ur die Zentral- |
| |
|_________________Australische-Zeitzone.______________________________________________________________________________|__
|__EMP____________mehrfach___________Pflicht____________________________________________________________Empf"anger__|__
|| Die Netzadresse der Empf"angerin(nen). ||
| Tritt diese INFORMATION mehrfach auf, muss dieses Nachricht an JEDE dieser |
| Empf"angerinnen weitergeleitet werden. Geschieht dies nicht "uber ein gemeinsames |
| |
| Routesystem, sind Kopien der Nachricht anzufertigen. |
| Bei diesem Kopiervorgang bekommen die einzelnen Kopien nur noch die EMP |
| Header, an die diese Kopie weitergehen soll, alle u"brigen (die u"ber ein anderes |
| |
| System erreicht werden sollen) werden als Kopienempf"anger (KOP Header) |
| |
|| eingetragen. ||
| Enth"alt eine der EMP-Angaben keinen "@", handelt es sich um eine "offentliche |
| Nachricht. Eine Nachricht kann in mehrere "offentliche Bretter geschickt werden, |
| |
| indem f"ur jedes Brett eine EMP-Information eingesetzt wird. Physikalisch wird |
| nat"urlich nur eine Kopie der Nachricht weitergereicht. Hier wird also - im |
| |
| Gegensatz zu den privaten Nachrichten - niemals kopiert. Hat ein System nicht |
| alle der in EMP Headern angegebenen Bretter bestellt, m"ussen dennoch alle EMP |
| |
| Header weitergegeben werden! Das gleiche gilt, wenn auf dem lokalen System nicht |
| |
| jedes Brett, das in einem EMP Header aufgef"uhrt wird, existiert. |
|_________________Ein_EMP_Header_darf_auch_einen_Realnamen_enthalten._________________________________________________|__
|__ERR____________Nur_einmal_________optional_________________________________________________________________Error__|_
| Falls dieser Header vorhanden ist, wurde die Nachricht von einem Programm |
| automatisch zur"uckgeschickt - entweder weil die Nachricht fehlerhaft oder die |
| |
| Empf"angerin unbekannt war. Der ERR Header enth"alt die Fehlermeldung im |
| |
|_________________Klartext.___________________________________________________________________________________________|__
|__ERSETZT___________________________optional_________________________________________________Nachricht_ersetzen__|____
| Gibt die Message-ID der Nachricht an, die von dieser ersetzt wird. Damit |
| kann daf"ur gesorgt werden, das von einer regelm"assig ver"offentlichten Information |
| |
| immer nur die aktuelle in einer MailBox vorhanden ist. Anwendungsbeispiele: |
| |
|_________________Serverstruktur,_MailBox-Listen,_ZMAPs,_FAQs_etc.____________________________________________________|_
^L
KAPITEL 3. DIE MO"GLICHEN HEADER-INFORMATIONEN 8
_____________________________________________________________________________________________________________________
|__FILE__________Nur_einmal_________optional____________________________________________________________Filename__|__
| Gibt den Dateinamen (ohne Directory!) der Datei an - zum Beispiel f"ur |
| |
|| Bin"arnachrichten oder Grafiken. ||
| ACHTUNG: je nach Betriebssystem des Absende-Systems, kann dieser Datei- |
| name beliebig lang sein und evtl. Sonderzeichen, Leerzeichen sowie nat"urlich |
| |
| mehrere Punkte enthalten! Jede Software, die diesen Header auswertet, um diese |
| Nachricht zu speichern, sollte darauf vorbereitet sein und entweder den Namen |
| |
| entsprechend k"urzen sowie ung"ultige Zeichen durch Ersatzdarstellungen ersetzen |
| |
|________________oder_bei_ung"ultigen_Namen_einen_eigenen_Namen_generieren.__________________________________________|_
|__KOM___________Nur_einmal_________optional__________________________________________________Kommentarl"ange__|_____
| L"ange des Kommentars in Byte. Wird z.B. f"ur Bin"arnachrichten, denen ein ASCII- |
| |
| Kommentar vorangestellt ist, gebraucht. Nach dem Header folgt der Kommentar |
| in der angegebenen L"ange, dann erst die Bin"ardaten. Die Bin"ardatenl"ange ist |
| |
| also LEN minus KOM. Ein Kommentar kann aber auch bei allen anderen |
| |
|| Nachrichtentypen vorangestellt werden. ||
| F"ur den Inhalt des Kommentars gelten IMMER die Regeln f"ur Standard- |
| Textnachrichten, auch wenn er einem Text mit alternativem Zeichensatz (und |
| |
|________________entsprechender_TYP-Information)_vorangestellt_ist.__________________________________________________|_
|__KOP___________merhfach___________optional________________________________________________Kopienempf"angerin__|____
| Falls eine Nachricht an mehrere Personen geschickt wurde, kann diese Information |
| die "ubrigen Empf"angerinnen auflisten. Gibt es mehrere Kopienempf"angerinnen, |
| |
| tritt diese Information mehrfach mit jeweils einer Empf"angeradresse auf (je eine |
| |
| KOP-Information pro Empf"angerin). |
| ACHTUNG: diese Information dient nur der Dokumentation f"ur die Empf"ang- |
| |
| erinnen, sie wird NICHT zum Steuern der Nachrichtenweiterleitung verwendet. |
| Falls eine KOP: Angabe gemacht wird, aber keine entsprechende EMP: Angabe |
| |
| vorhanden ist, wird die routende Software sich NICHT bem"uhen, dieser KOP- |
| Adressatin eine Kopie zuzusenden. Die Software wird vielmehr davon ausgehen, |
| |
| dass diese Adressatin ihre Kopie bereits "uber einen anderen Routweg erhalten hat |
| |
|________________(bzw._erhalten_wird)._______________________________________________________________________________|_
|__LDA___________Nur_einmal_________optional________________________________________________________L"oschdatum__|___||
| Ein Datum, ab dem diese Nachricht automatisch gel"oscht werden soll/kann. Kann |
| f"ur Veranstaltungshinweise oder andere Nachrichten mit "Verfallsdatum" (z.B. die |
| |
|________________urgent_actions_von_amnesty_international)_verwendet_werden._________________________________________|_
|__LEN___________Nur_einmal_________Pflicht_________________________________________________________________L"ange__|_
| Die L"ange des INHALTS (alles, was hinter dem Header noch zu dieser Nachricht |
| |
|________________geh"ort)_in_Byte._Auch_die_L"ange_0_ist_erlaubt.____________________________________________________|_
|__MAILER________Nur_einmal_________optional_______________________________________________________________Mailer__|_
| Gibt den Namen des (von der Absenderin, bzw. vom konvertierenden Gateway) |
| verwendeten Mailers an (pure Werbung, aber immerhin f"ur Userinnen unsichtbar |
| |
| :-) Dient der Fehlererkennung im Netzwerk. Hier sollte eine eindeutige Kennung |
| |
|________________der_Software_incl._Versions_/_Releasenummer_stehen._________________________________________________|_
|__MID___________Nur_einmal_________Pflicht__________________________________________________________Message-ID__|___||
| Die Message-ID muss wie eine g"ultige Adresse (ohne Realname) aussehen (siehe |
| oben) und darf innerhalb von zwei Jahren weltweit nicht wiederholt werden. Dazu |
| |
| MU"SSEN Message-IDs eine Domain enthalten, falls dem System keine Internet- |
| |
| Domain zugeordnet ist, muss hier zumindest ".zer.sub.org" eingetragen werden. |
| POINTS werden besonders behandelt: die MailBox benutzt nur den lokalen Teil |
| |
| der vom Point gelieferten ID (also alles vor dem @) und h"angt einen Klammeraffen |
| '@' und den Pointnamen, gefolgt von einem Punkt und dem MailBox-Namen, |
| |
| gefolgt von der MailBox-Domain an. So ist die Eindeutigkeit von Point-Message- |
| |
| IDs weltweit garantiert. |
|________________________________________________________________________________________(Fortsetzung_n._Seite)__|___
^L
KAPITEL 3. DIE MO"GLICHEN HEADER-INFORMATIONEN 9
_________________________________________________________________________________________________________________
|__MID_________________________________________________________________________________________(Fortsetzung)__|__
| Beispiel: der Point "BIONIC01" sendet eine Nachricht mit der Message-ID |
| "aH24.8281@BIONIC01.zer.de". |
| Daraus wird auf der BIONIC die Message-ID |
| "aH24.8281@BIONIC01.BIONIC.zer.de". |
| Points d"urfen auch nur den lokalen Teil der ID liefern (also von sich aus den |
| @, Systemname und Domain entfallen lassen). Points k"onnen auf eine Message- |
| |
| ID notfalls auch v"ollig verzichten, in diesem Fall muss die MailBox eine eigene |
| |
| erzeugen. |
| Die Message-ID dient zur eindeutigen Identifikation dieser Nachricht. Sollte |
| |
| innerhalb von zwei Jahren eine Nachricht mit einer gleichen Message-ID noch |
| einmal auftreten, ist dies eine "Rekursion", d.h. die Nachricht ist "uber einen |
| |
| Umweg noch einmal zur MailBox gelangt und kann deshalb gel"oscht werden. Sie |
| |
| darf auf keinen Fall weitergeleitet werden. |
| Eine praktische Implementationsm"oglichkeit ist es z.B., alle Message-IDs f"ur 90 |
| Tage aufzubewahren und alle eingehenden Nachrichten gegen diese Datenbank zu |
| |
| pr"ufen. Eingehende Nachrichten, die "alter als 90 Tage sind, k"onnen bedenkenlos |
| |
|| entsorgt werden, ohne die Message-ID zu testen. ||
| Der Rekursionstest anhand der Message-ID (und zwar AUSSCHLIESSLICH |
| anhand dieser) muss von jeder Software durchgef"uhrt werden! O"ffentliche Nach- |
| |
| richten, die als Rekursion erkannt wurden, d"urfen nicht weitergeroutet werden. |
| Pers"onliche Nachrichten werden nicht auf Rekursion gepr"uft, lediglich das Ziel- |
| |
| system der Nachricht darf doppelte pers"onliche Nachrichten ausfiltern. |
|____________In_Message-IDs_sind_die_Zeichen_'_<',_'>_'_und_'/'_verboten.________________________________________|_
|__OAB_______Nur_einmal_________optional______________________________________________Original-Absenderin__|_____
| Falls eine Nachricht manuell oder per Verteiler weitergeleitet wurde, steht hier, |
| |
|____________wer_die_Nachricht_original_verschickt_hat.__________________________________________________________|_
|__OEM_______mehrfach___________optional_____________________________________________Original-Empf"angerin__|____
| Falls eine Nachricht manuell oder per Verteiler weitergeleitet wurde, steht hier die |
| |
|____________urspr"unglich_angegebene_Empf"angerin.______________________________________________________________|_
|__ORG_______Nur_einmal_________optional________________________________________________________Organisation__|__||
| Eine kurze, einzeilige Beschreibung der hinter der Absenderin stehenden Or- |
| ganisation, z.B. "Borland Deutschland GmbH, Starnberg, F.R.G.". Wird eine |
| |
| solche Information eingesetzt und die Nachricht gibt NICHT die offizielle Meinung |
| der Organisation wieder, wird im Nachspann (Signatur) der Nachricht meist der |
| |
| "Standard- Disclaimer" eingef"ugt: "Meine Meinung ist NUR meine Meinung. Sie |
| |
|____________wird_von_meiner_Arbeitgeberin_weder_geteilt_noch_bezahlt."__________________________________________|_
|__PGP_______Nur_einmal_________optional__________________________________________________________Public-Key__|__
| Dieser Header beinhaltet einen Public-Key in hexadezimaler Schreibweise f"ur PGP |
| |
|____________(Pretty-good-privacy)_______________________________________________________________________________|_
|__POST______Nur_einmal_________optional_______________________________________________________Post-Adresse__|___
| Wenn die Absenderin einer Nachricht auch u"ber andere Medien, z.B. per Post, |
| erreichbar sein m"ochte, kann sie in diesem Header ihre postalische Anschrift |
| |
| unterbringen. Die einzelnen Anschriftenzeilen werden hintereinander geschrieben |
| |
|____________und_jeweils_durch_Semikola_";"_getrennt.____________________________________________________________|_
|__PRIO______Nur_einmal_________optional_____________________________________________________________Priorit"at__|
| (ohne diesen Header gilt Priorit"at 0) |
| Gibt die Dringlichkeit der Zustellung an. Zur Zeit sind folgende Dringlichkeiten |
| |
| definiert: |
| 0 = normal (per Routing) |
| 10 = direkt |
|____________20_=_Eilmail_(direkt_mit_sofortiger_Auslieferung)_________________________________________|_________
^L
KAPITEL 3. DIE MO"GLICHEN HEADER-INFORMATIONEN 10
___________________________________________________________________________________________________________________________
|__ROT_________________Nur_einmal_________Pflicht_____________________________________________________________Routeweg__|__
| Jedes System tr"agt sich hier ein, wenn es die Nachricht empf"angt. Z-Netz Systeme |
| werden hier mit Domain eingetragen (".zer.sub.org", falls keine andere bekannt |
| |
| ist). Eine Nachricht (auch eine PM) darf niemals an ein System weitergereicht |
| |
| werden, dessen Name bereits im Routeweg steht. |
| Falls eine PM "uber ein System zugestellt werden muss, das bereits im Routeweg |
| steht, sollte diese Nachricht dem Sysop vorgelegt werden (Achtung: Datenschutz! |
| |
| Nur die Header, nicht der Nachrichteninhalt darf sichtbar sein!), da offenbar ein |
| |
|| Ping-Pong-Routing besteht. ||
| Als erstes System tr"agt sich hier das Absender-System ein (damit auch dieses |
| die Nachricht nicht noch einmal bekommt). Erreicht die Nachricht das n"achste |
| |
| System, setzt dieses seinen eigenen Namen (incl. Domain) gefolgt von einem ' !' |
| vor den alten Inhalt dieser Information. Dazu ein Beispiel: auf der BIONIC.zer.de |
| |
| wird eine Nachricht erzeugt: "ROT: BIONIC.zer.de". Nun erreicht diese Nachricht |
| |
|______________________die_BI-LINK.owl.de:_"ROT:_BI-LINK.owl.de!BIONIC.zer.de".____________________________________________|_
|__SPERRFRIST__________Nur_einmal_________optional____________________________________________________________G"ultig_ab__|_||
| Ein Datum im Format wie EDA. Vor diesem Datum wird diese Nachricht NICHT |
| angezeigt. Damit kann z.B. eine Sperrfrist bei Pressemeldungen eingehalten |
| |
|______________________werden._____________________________________________________________________________________________|_
|__STAT________________merhfach___________optional__________________________________________________Nachrichtenstatus__|___
| Beschreibt, was die Nachricht ist: Falls dieser Header fehlt, handelt es sich um eine |
| |
| normale Mail. Wenn der Header vorhanden ist, gibt es folgenden Eintr"age: |
| DES Nachricht ist mit DES verschl"usselt. (Data Encryption |
| |
| Standard) |
| PGP Nachricht ist mit PGP verschl"usselt. (Pretty Good Privacy, |
| |
| einer RSA Implementation) |
| EB Nachricht ist eine automatisch verschickte |
| |
| Empfangsbest"atigung. |
| CTL Nachricht ist eine Kontrollnachricht, die - auch wenn sie defekt |
| |
|| ist - nicht zur"uckgeschickt werden darf. ||
| AUTO Gibt an, das es sich bei dieser Nachricht um eine regelmaessig |
| aktualisierte Information handelt. Welche kann aus dem FILE: |
| |
| Header und dem EMP: Header entnommen werden, der BET: |
| Header ist hier nicht(!) auszuwerten (weil da z.B. "Ausgabe |
| |
| vom xx.xx.xx" drin stehen kann). Diese Nachricht kann von |
| entsprechenden Hilfsprogrammen erkannt und automatisch (je |
| |
| nach Konfiguration) in einen FileServer, ein lokales Brett oder |
| |
| ein spezielles Exclude-Verzeichnis uebernommen werden. |
| CRYPT Die Nachricht ist dann mit dem mit diesem Absender |
| |
|_________________________________________vereinbarten_Verfahren/Passwort_verschluesselt.__________________________________|_
|__TELEFON_____________Nur_einmal_________optional_____________________________________________________Telefonnummer__|____||
| Hier kann die Absenderin ihre Telefonnummer(n) unterbringen. Es wird die |
| |
| internationale Schreibweise verwendet, mit vorangestelltem "V" f"ur Voice, "F" f"ur |
| Fax oder "B" f"ur MailBox (BBS). Bei Voice-Nummern wird ein "Q" nachgestellt, |
| |
| wenn ein Anrufbeantworter vorhanden ist. Alle Nummern werden durch ";" |
| oder Leerzeichen getrennt. Beispiel: "V+49-521-561345Q F+49-521-561785 |
| |
| B+49-521-193004". Bei kombinierten Nummern werden die Kennbuchstaben |
| |
|______________________hintereinandergestellt:_VF+49-521-562342Q.__________________________________________________________|
^L
KAPITEL 3. DIE MO"GLICHEN HEADER-INFORMATIONEN 11
____________________________________________________________________________________________________________________________
|__TYP__________________Nur_einmal_______________optional____________________________________________________________Typ__|_||
| N"ahere Beschreibung des Dateityps. Definiert, um welche Art von Bin"ardatei es |
| sich handelt (z.B. TIFF, GIF, PCX, ...). Alle unbekannten TYP Informationen |
| |
| werden als reine Bin"arnachricht aufgefasst. Definiert sind die Typkennungen |
| BIN allgemeine Bin"arnachricht |
| TRANSPARENT Textnachricht ohne Umlautwandlung |
| Beim Inhalt des TYP Headers wird nicht zwischen Gross- und Kleinschreibung |
| |
| unterschieden. |
|_______________________Falls_kein_TYP-Header_vorhanden_ist,_handelt_es_sich_um_eine_Textnachricht._________________________|_
|__WAB__________________Nur_einmal_______________optional_____________________________________Weiterleitungsabsender__|_____
| Der WAB: darf immer angegeben werden und ist gegebenenfalls mit dem ABS: |
| |
| identisch. |
| Treten bei der Zustellung der Nachricht Fehler auf, wird davon der WAB |
| |
| informiert, nicht der ABS. |
| Nachrichten von Mailing-Listen (Netzwerk-Verteiler) enthalten in der Regel die |
| |
| Adresse des Listen-Betreuers als WAB, waehrend der ABS: aus der Mail an den |
| Verteiler uebernommen wird. Dadurch gehen Antworten an den urspruenglichen |
| |
| Autor, Fehlermeldungen ueber falsche Eintraege im Verteiler aber an dessen |
| |
| Verwalter. |
| Dies wird in der RFC Welt als "Envelope-Adresse" bezeichnet. (EMP: und WAB: |
| |
|_______________________sind_die_Envelope-Adressen_fuer_ZCONNECT).__________________________________________________________|_
|__ZNETZ-ABS____________Nur_einmal_______________optional__________________________________Konvertierungs-Absender__|_______||
| Absenderangabe f"ur die Konvertierung in das ZNETZ-Format. Hier wird der |
| |
| Absendername so gespeichert, dass er im Z-Netz adressierbar bleibt. In den |
| Absender-Header (ABS) wird eine ZConnect-konforme Adresse eingetragen, die |
| |
| aus dieser konvertiert wurde. Diese Information kann nur einmal proHEADER |
| auftreten. Wird eine Nachricht von ZConenct nach Z-Netz gewandelt, wird |
| |
| ebenfalls nach diesem Header gesucht und bei einem Treffer der Inhalt auf dem |
| |
|_______________________weiteren_Weg_als_Absenderangabe_benutzt_____________________________________________________________|_
|__ZNETZ-TEXT___________mehrfach_________________optional__________________________________________Konvertierungstext__|____
| Textheader bei Konvertierung in das ZNETZ-Format. Dies k"onnen die |
| verschiedensten Inhalte sein. Wenn die Nachricht von ZConnect nach Z-Netz |
| |
| gewandelt wird, werden die Inhalte der Z-Netz-Text-Header bei Textnachrichten |
| |
|_______________________dem_eigentlichen_Naachrichteninhalt_vorangestellt.__________________________________________________|
3.2 Weitere Headerzeilen von TheAnswer
Die hier gezeigten Header-IDs geh"oren nicht zum Standard-Umfang von ZConnect, und werden nur von
TheAnswerIII oder wenigen anderen Pointprogrammen benutzt.
___________________________________________________________________________________________________________________________
|__X-TA-__________________mehrfach____________optional_________________________________________TheAnswer-Kennung__|________||
| Alle TheAnswerIII-spezifischen Header beginnen mit diesem Code. Dadurch |
| soll verhindert werden, dass andere Programme, die ebenfalls eigene Header |
| |
|_________________________verwenden,_nicht_gleichlautende_Header_mit_anderem_Sinn_definieren.______________________________|_
|__X-TA-ZNETZ-ID__________Nur_einmal__________optional_____________________________________________ZNetz-Message-ID__|_____||
| Wird eine Nachricht im alten Z-NETZ-Format einsortiert, wird sie mit einer |
| ZConnect-Message-ID versehen. Die alte MessageID wird mit diesem Header |
| |
|_________________________jedoch_bei_TheAnswerIII_erhalten.________________________________________________________________|
^L
KAPITEL 3. DIE MO"GLICHEN HEADER-INFORMATIONEN 12
________________________________________________________________________________________________________________________________
|__X-TA-ZNETZ-EMP_:____________Nur_einmal_________optional______________________________________________ZNetz-Empf"anger__|_____
| Netzadressen (siehe auch EMP, ABS), jedoch keine Brettnamen werden bei |
| |
| der Wandlung von Z-Netz nach ZConnect ver"andert. In der Regel wird eine |
| ZConnect-kompatible Domain angeh"angt, die "zer.sub.org" lautet. Wird eine |
| |
| Nachricht im alten Z-NETZ-Format einsortiert, wird sie so gewandelt und der |
| |
|______________________________alte_Empf"angername_in_diesem_Header_gespeichert._______________________________________________*
*|__
|__REPLY-LEVEL_________________Nur_einmal_________optional________________________________________________Antwortenz"ahler__|__*
*_||
| Wie schon in der TheAnswerIII-Dokumentation erkl"art, werden RE-Zeichen |
| |
| und andere K"urzel f"ur "Dies ist eine Antwort auf:" beim Einsortieren aus dem |
| Betreff gefiltert und als Zahl neben dem Betreff im Inhaltmen"u dargestellt. |
| |
| Dieser Zahlenwert wird bei TheAnswerIII mit dieser Header-ID in der |
| nachricht gespeichert. Dieser Header beginnt nicht mit "X-TA" da er offiziell |
| |
| auch von anderen Pointprogramm benutzt wird und dabei den gleichen Sinn |
| |
|______________________________und_Zweck_erf"ullt._Beachte_auch_den_Display-Header_"REPLY"_____________________________________*
*|_
3.3 Lokale Headerzeilen von TheAnswer
Diese lokalen Header-IDs werden nur innerhalb von TheAnswerIII benutzt. Diese Header werden nicht ins
Netz geschickt, sondern beim Erzeugen der Uploaddatei ausgefiltert oder netzgerecht umgewandelt. Um eine
externe Manipulation dieser Header zu verhindern, werden Nachrichten, die von aussen einsortiert werden
und diese Header enthalten als illegal betrachtet.
____________________________________________________________________________________________________________________________
|__X_TA_VERS____________Nur_einmal_________optional________________________________________________TheAnswer-Version__|_____||
| Dieser Header war dazu vorgesehen, die TheAnswerIII-Version zu speichern, mit |
| eineNachricht einsortiert oder generiert wurde. Dieser Header wird jedoch in der |
| |
|_______________________Version_3.00_nicht_benutzt._________________________________________________________________________|_
|__X_TA_ROBOT___________Nur_einmal_________optional___________________________________________Mail_mit_Signumverbot__|______
| Nachrichten, die diesen Header enthalten, werden mit keiner Unterschrift versehen |
| und erhalten kein TheAnswerIII-Signum am Ende der Nachricht. Dieser Header |
| |
| wird von TheAnswerIII automatisch gesetzt, wenn Nachrichten an ein MAPS- |
| |
|_______________________Systemgehen._(Mehr_Maps_siehe_TheAnswerIII-Dokumentation)___________________________________________|_
|___NEU_________________Nur_einmal_________optional______________________________________________________Neuer_Header__|____||
| Dieser Pseudo-Header wird als Vorgabe erzeugt, wenn man im Nachrichten-Editor |
| einenneuen Headereintrag w"unscht. Er muss danach in eine g"ultige Header-ID |
| |
|_______________________verwandelt_werden.__________________________________________________________________________________|_
|__X_TA_CRYPT___________Nur_einmal_________optional____________________________________________________Codierverfahren__|___||
| Nachrichten mit diesem Header werden codiert, sobald sie in die Uploaddatei |
| kopiert werden, oder in einem Netcall-Format ausgelagert bzw. gelesen werden. |
| |
|_______________________Im_Header_ist_das_verwendete_Codierverfahren_gespeichert.___________________________________________|_
|__X_TA_PW______________Nur_einmal_________optional___________________________________________________Codier-Passwort__|____||
| Das Passwort, mit dem eine Nachricht beim kopieren ins Spoolbrett codiert werden |
| soll. Der Header wird nach der Codeirung nat"urlich entfernt und geht nicht ins |
| |
|_______________________Netz._______________________________________________________________________________________________|_
|__X_TA_SCRIPT__________Nur_einmal_________optional_______________________________________________________Codier-Script__|__
| Wenn das verwendete Codierverfahren z.B. PMCrypt ist, muss mit einem externen |
| Batch codiert werden. in diesem Header wird der Dos-Aufruf f"ur das Script |
| |
| gespeichert, dass beim kopieren der Nachricht in die Uploaddatei ausgef"uhrt wird, |
| |
|_______________________um_die_Nachricht_wirklich_zu_codieren._(Wird_dabei_nat"urlich_ausgebaut)____________________________|
3.4 Weitere Headerzeilen
Neue Headerzeilen k"onnen jederzeit definiert werden. JEDE Software muss ihr unbekannte Zeilen
UNVERA"NDERT weitergeben. F"ur lokale Erweiterungen wird garantiert, dass niemals eine Headerzeile mit
^L
KAPITEL 3. DIE MO"GLICHEN HEADER-INFORMATIONEN 13
"X-" beginnen wird. Sie k"onnen also gefahrlos eigene Headerzeilen wie z.B. "X-Euromail-Version: 22.5"
erzeugen.
Headerzeilen, die mit "U-" beginnen, sind UUCP-Header, entsprechen also RFC822/1036 bzw.
entsprechenden Nachfolgestandards. UUCP oder Internet-Gateways k"onnen auf diese Weise Informationen,
f"ur die es im ZCONNECT zur Zeit noch keine Entsprechung gibt, 1:1 durchreichen. Beispiel: "U-Date: Thu,
12 Jan 1987 PDST" entspricht der RFC-1036 Header-Zeile "Date: Thu, 12 Jan 1987 PDST". (Wobei in
diesem Fall die Information gleichwertig mit dem EDA Header transportiert werden kann, aber es ist ja nur
ein Beispiel...)
^L
Index
ABS :::::::::::::::::::::::::::::::::::::: 6 PGP::::::::::::::::::::::::::::::::::::: 10
ANTWORT-AN :::::::::::::::::::::::::: 6 PGP :::::::::::::::::::::::::::::::::::::: 9
AUTO ::::::::::::::::::::::::::::::::::: 10 POST::::::::::::::::::::::::::::::::::::: 9
PRIO ::::::::::::::::::::::::::::::::::::: 9
BET :::::::::::::::::::::::::::::::::::::: 6
BEZ :::::::::::::::::::::::::::::::::::::: 6 REPLY-LEVEL:::::::::::::::::::::::::: 12
BIN:::::::::::::::::::::::::::::::::::::: 11 REPLY ::::::::::::::::::::::::::::::::::: 5
RFC-1036 ::::::::::::::::::::::::::::::: 13
CRYPT:::::::::::::::::::::::::::::::::: 10 ROT::::::::::::::::::::::::::::::::::::: 10
CTL ::::::::::::::::::::::::::::::::::::: 10
SERVER:::::::::::::::::::::::::::::::::: 4
DATUM :::::::::::::::::::::::::::::::::: 3 SPERRFRIST ::::::::::::::::::::::::::: 10
DDA:::::::::::::::::::::::::::::::::::::: 6 STAT:::::::::::::::::::::::::::::::::::: 10
DES ::::::::::::::::::::::::::::::::::::: 10
DISKUSSION-IN ::::::::::::::::::::::::: 6 TELEFON::::::::::::::::::::::::::::::: 10
DOMAIN ::::::::::::::::::::::::::::::::: 4 TRANSPARENT :::::::::::::::::::::::: 11
TYP::::::::::::::::::::::::::::::::::::: 11
EB:::::::::::::::::::::::::::::::::::::::10
EB:::::::::::::::::::::::::::::::::::::::: 6 U-::::::::::::::::::::::::::::::::::::::: 13
EDA:::::::::::::::::::::::::::::::::::::: 7 UNKNOWN :::::::::::::::::::::::::::::: 5
EMP:::::::::::::::::::::::::::::::::::::: 7 USER::::::::::::::::::::::::::::::::::::: 4
ENDIF:::::::::::::::::::::::::::::::::::: 4
ERR :::::::::::::::::::::::::::::::::::::: 7 WAB :::::::::::::::::::::::::::::::::::: 11
ERSETZT :::::::::::::::::::::::::::::::: 7
X-::::::::::::::::::::::::::::::::::::::: 13
FILE:::::::::::::::::::::::::::::::::::::: 8 X-TA-ZNETZ-EMP:::::::::::::::::::::: 12
X-TA-ZNETZ-ID :::::::::::::::::::::::: 11
HEUTE::::::::::::::::::::::::::::::::::: 5 X-TA- ::::::::::::::::::::::::::::::::::: 11
X_TA_CRYPT ::::::::::::::::::::::::::: 12
IF :::::::::::::::::::::::::::::::::::::::: 4 X_TA_PW ::::::::::::::::::::::::::::::: 12
X_TA_ROBOT::::::::::::::::::::::::::: 12
JETZT ::::::::::::::::::::::::::::::::::: 5 X_TA_SCRIPT::::::::::::::::::::::::::: 12
KOM ::::::::::::::::::::::::::::::::::::: 8 X_TA_VERS ::::::::::::::::::::::::::::: 12
KOP:::::::::::::::::::::::::::::::::::::: 8 ZEIT ::::::::::::::::::::::::::::::::::::: 3
LDA :::::::::::::::::::::::::::::::::::::: 8 ZNETZ-ABS :::::::::::::::::::::::::::: 11
LEN :::::::::::::::::::::::::::::::::::::: 8 ZNETZ-TEXT :::::::::::::::::::::::::: 11
MAILER:::::::::::::::::::::::::::::::::: 8
MID :::::::::::::::::::::::::::::::::::::: 8
NAME:::::::::::::::::::::::::::::::::::: 4
_NEU_ ::::::::::::::::::::::::::::::::::: 12
OAB:::::::::::::::::::::::::::::::::::::: 9
OEM ::::::::::::::::::::::::::::::::::::: 9
ORG:::::::::::::::::::::::::::::::::::::: 9
14
